web/packages/studio/src/routes/DataDesignerJobDetailsRoute/builderConfig.ts (1)

17-44: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Mark summary interface fields as readonly.

These interfaces represent parsed summary snapshots and should be immutable at the type level.

Proposed diff

 export interface BuilderConfigColumnSummary {
-  name: string;
-  type: string;
-  modelAlias?: string;
+  readonly name: string;
+  readonly type: string;
+  readonly modelAlias?: string;
 }
 
 export interface BuilderConfigModelSummary {
-  alias: string;
-  model: string;
-  provider?: string;
+  readonly alias: string;
+  readonly model: string;
+  readonly provider?: string;
 }
 
 export interface BuilderConfigSeedSummary {
-  type: string;
-  samplingStrategy?: string;
+  readonly type: string;
+  readonly samplingStrategy?: string;
 }
 
 export interface BuilderConfigSummary {
-  columnCount: number;
-  columns: BuilderConfigColumnSummary[];
-  columnTypeBreakdown: Array<{ type: string; count: number }>;
-  models: BuilderConfigModelSummary[];
-  seed?: BuilderConfigSeedSummary;
-  constraintCount: number;
-  profilerCount: number;
-  processorNames: string[];
-  libraryVersion?: string;
+  readonly columnCount: number;
+  readonly columns: BuilderConfigColumnSummary[];
+  readonly columnTypeBreakdown: Array<{ type: string; count: number }>;
+  readonly models: BuilderConfigModelSummary[];
+  readonly seed?: BuilderConfigSeedSummary;
+  readonly constraintCount: number;
+  readonly profilerCount: number;
+  readonly processorNames: string[];
+  readonly libraryVersion?: string;
 }

As per coding guidelines: web/**/*.{ts,tsx}: Use \readonly` for immutable properties in TypeScript interfaces and types`.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web/packages/studio/src/routes/DataDesignerJobDetailsRoute/builderConfig.ts`
around lines 17 - 44, Add the readonly keyword to all property declarations in
the four summary interfaces (BuilderConfigColumnSummary,
BuilderConfigModelSummary, BuilderConfigSeedSummary, and BuilderConfigSummary)
to mark them as immutable at the type level. For each property in these
interfaces, prefix the property name with the readonly keyword to ensure the
data structures represent immutable snapshots that cannot be modified after
creation.

Source: Coding guidelines

web/packages/studio/src/routes/DataDesignerJobDetailsRoute/DataDesignerConfigPanel.tsx (1)

14-14: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Import FC as type-only.

FC is only used in type positions here.

Proposed diff

-import { FC, useMemo } from 'react';
+import { useMemo, type FC } from 'react';

As per coding guidelines: web/**/*.{ts,tsx}: Use \import type` for type-only imports in TypeScript`.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@web/packages/studio/src/routes/DataDesignerJobDetailsRoute/DataDesignerConfigPanel.tsx`
at line 14, The import statement at the top of DataDesignerConfigPanel.tsx
imports both FC and useMemo from 'react' using a single import statement. Since
FC is only used in type positions (as a functional component type), it should be
imported using import type syntax instead of regular import. Split the import
statement so that FC is imported with import type while useMemo remains in a
regular import statement.

Source: Coding guidelines

web/packages/studio/src/routes/DataDesignerJobDetailsRoute/JobOutputFilesetSection.tsx (1)

20-20: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Convert type-only React imports to import type.

ComponentProps and FC are type-only and should use import type in this TSX file.

Proposed fix

-import { ComponentProps, FC, useCallback, useEffect, useMemo, useState } from 'react';
+import { useCallback, useEffect, useMemo, useState } from 'react';
+import type { ComponentProps, FC } from 'react';

As per coding guidelines, web/**/*.{ts,tsx}: Use import type for type-only imports in TypeScript.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@web/packages/studio/src/routes/DataDesignerJobDetailsRoute/JobOutputFilesetSection.tsx`
at line 20, In the import statement at the top of JobOutputFilesetSection.tsx,
separate the type-only imports from the runtime imports. Move ComponentProps and
FC to a new line using import type syntax, keeping useCallback, useEffect,
useMemo, and useState in the regular import statement from React. This ensures
type-only imports are clearly distinguished from runtime dependencies according
to the project's TypeScript guidelines.

Source: Coding guidelines

web/packages/studio/src/routes/DataDesignerJobDetailsRoute/index.tsx (1)

25-25: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use import type for FC in this TSX module.

FC is type-only and should be imported with import type to match the TypeScript guideline.

Proposed fix

-import { FC, useState } from 'react';
+import { useState } from 'react';
+import type { FC } from 'react';

As per coding guidelines, web/**/*.{ts,tsx}: Use import type for type-only imports in TypeScript.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web/packages/studio/src/routes/DataDesignerJobDetailsRoute/index.tsx` at line
25, The import statement at the top of the DataDesignerJobDetailsRoute file
imports FC as a type-only import along with useState in a single import
statement. Separate this into two imports: create a type-only import for FC
using import type, and keep a regular import for useState from react. This
ensures that type-only imports are explicitly marked as such, following
TypeScript guidelines that help with tree-shaking and code clarity.

Source: Coding guidelines

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

web/packages/studio/src/components/dataViews/ExperimentGroupDataView/index.tsx (1)

117-137: 🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

Replace the old metadataKeys memo instead of duplicating it.

Lines 129-137 redeclare metadataKeys, and tableData is not defined anywhere in this component. This is a build break. Remove the stale block and keep a single memo wired to an in-scope data source.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@web/packages/studio/src/components/dataViews/ExperimentGroupDataView/index.tsx`
around lines 117 - 137, The component has a duplicated metadataKeys memo and the
second block uses tableData, which is not defined in ExperimentGroupDataView.
Remove the stale redeclaration and keep only the existing useMemo wired to the
in-scope orderedData source so the metadata key computation stays single and
buildable.